How to migrate to new OSH software without losing historical records or evidence
Migrating OSH software means moving information that must remain understandable after the change. Loading rows is not enough: an action may depend on an assessment, a document on its version, and a record on the entity or location it belonged to when it was created.
Define acceptance criteria before starting the project. The Explora entry on digital evidence in occupational risk prevention explains why record context matters. Migration should preserve the necessary information, its relationships and the agreed conditions for access and consultation after the transition.
Inventory the information you already hold
Locate databases, spreadsheets, shared folders, attachments and archives from previous applications. Record the owner, format, volume, period and sensitivity of each source. Identify current records, historical information and duplicates, together with the person who can validate what each category means.
Decide what belongs in the operational system and what should remain in a searchable archive. This decision must reflect applicable retention obligations and intended use instead of copying everything indiscriminately. The Explora entry on preventive documentation helps organise the categories that require review.
Define field mappings and transformation rules
Create a mapping table connecting every source field with its destination. Include meaning, format, transformation rules and treatment of missing values. A site code needs a stable relationship: renaming a location should not erase the historical location of a preventive activity.
Separate statuses that look similar but mean different things. “Performed”, “validated” and “closed” may describe different stages. If the destination system uses another model, document the equivalence and retain the original value where it is necessary to interpret the historical record correctly.
Dates also need attention. Creation, execution, approval and due dates are not interchangeable. Check time zones where time-stamped records support international operations. Every transformation should be explainable to the responsible team rather than hidden inside an import process or a supplier’s technical script.
Test relationships and documents as well as counts
Select a representative sample of older, recent, incomplete and complex records. Include site changes, documents with several versions and actions linked to multiple activities. Use an appropriately restricted test environment and check the complete workflow instead of reviewing only a spreadsheet of import results.
- Reconciliation: compare totals by entity, site, type and period, explaining differences.
- Integrity: verify identifiers, references and relationships between records.
- Documents: open attachments and confirm the correct case and version.
- Access: test authorised roles and restrictions that must remain in place.
- Usefulness: ask a user to find a case and understand its sequence of decisions.
Matching totals are not proof of a correct migration. Two documents attached to the wrong cases can preserve the file count while changing the evidence available to the organisation. Record the correction and repeat the affected test rather than accepting unexplained differences.
Plan the operational transition
Agree when the final extraction takes place, what changes may occur during import and how those changes will be captured. Establish a checkpoint for deciding whether users can begin working in the new system. The acceptance owner needs test results and a visible list of unresolved issues.
A rollback plan explains how work continues if launch fails. Identify information created during the transition, the authoritative system and the people responsible for communicating the decision. Allowing both systems to remain editable without clear rules encourages conflicting versions and makes later reconciliation harder.
A useful validation example
Imagine a historical assessment connected to an action closed after a site transfer. The test should retrieve the assessment, confirm its original location, show the change and open the closure evidence. This illustrative example requires checking relationships, not merely individual columns or file availability.
Health information needs specific access and handling arrangements. Review the entry on health data protection in OSH to distinguish operational needs from clinical information and determine who should participate in migration.
Include this work in the implementation plan and the total software budget. When considering Sabentis OSH software, ask for a migration proposal that states scope, responsibilities, exclusions and acceptance evidence.
A practical checklist for migration acceptance
Prepare a short acceptance record explaining the information delivered, the checks performed and any exclusions. This allows the decision to be understood without relying on the implementation team’s memory.
- Keep a dated inventory of source files and the delivered dataset, identifying who is responsible for their custody.
- List rejected records and decide on correction, archiving or justified exclusion before closing the migration.
- Test searches using former names, accented characters and documents that changed location while the project was underway.
- Confirm an end date for temporary migration-team permissions and control all working copies created during the project.
- Document how historical material retained outside the new system can be located and who will maintain that access.
Frequently asked questions about migrating prevention records
Should every historical record move into the new software?
Not necessarily. First distinguish information required for operations from material that must remain in a searchable archive. The decision depends on use and the obligations applying to each category. A separate archive can be appropriate if it preserves integrity, context and access for authorised people.
Is comparing imported record counts enough?
No. Counts help reconciliation, but do not independently reveal swapped documents, incorrectly interpreted dates or broken relationships. Combine overall comparison with complete-case and exception tests, retaining an explanation of differences and accepted issues so that the basis for acceptance remains understandable afterwards.
Can real records be used to test the migration?
Only where the need is justified and appropriate safeguards are in place. Consider fictional or properly anonymised data first. Where real personal data is necessary, define who can access it, where it is hosted, its permitted use and when the test copies will be deleted.
When should access to the old system be cancelled?
After validating the migrated information and resolving how archived material will remain accessible. Agree transition and contractual conditions before cancellation. Avoid retaining unnecessary access, but do not lose the only way of recovering evidence that has not yet been validated or transferred.
Legislation and sources consulted
- European Union: General Data Protection Regulation: Articles 5, 28 and 32: processing principles, processor arrangements and security where the European framework applies.
- Colombia: Data Protection Act 1581 of 2012: Article 4: data quality, restricted access, security and confidentiality in Colombia. Retention periods also require assessment of category-specific rules.
Sources consulted on 6 October 2026. Checklists and examples are practical implementation proposals.
